소프트웨어 아키텍처 The Hard Parts 1주차 - 김도경 #587
Conversation
benscookie
added
2026
Software Architecture: The Hard Parts
benscookie
requested review from
GeunJuLEE,
TaeHyoungKwon,
chichoon,
dhlee3994,
jongfeel,
tttghost and
ymkim97
Summary of ChangesHello @benscookie, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 이 PR은 '소프트웨어 아키텍처 The Hard Parts' 책의 1~3장을 읽고 저자가 이해한 핵심 개념과 인사이트를 정리한 문서입니다. 아키텍처 결정 기록(ADR), 피트니스 함수, 아키텍처 퀀텀, 모듈화의 비즈니스 동인 등 주요 아키텍처 원칙에 대한 저자의 해석과 함께, 이를 실제 XR 프로젝트에 어떻게 적용할지에 대한 구체적인 계획을 담고 있습니다. 또한, 팀원들과 논의하고 싶은 질문들을 포함하여 학습 내용을 공유하고 토론을 유도하는 목적을 가집니다. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
우측에 있는 |
Co-Authored-By: Claude Opus 4.5 <[email protected]>
benscookie
force-pushed
the
kimdokyung-2026-week1
branch
from
873080f to
b6113f4
Compare
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
|
|
||
| ## 4. XR 프로젝트에 적용 | ||
|
|
||
| 실시간 렌더링 상태와 행동 로그를 다른 저장소·스키마로 나눠 응답 속도와 배치를 분리할 계획이다. ADR 템플릿은 `문제 → 옵션 → 선택 이유 → 부작용 → 재검토 조건` 순으로 짧게 쓰면서도 핵심을 잡을 생각이다. CI에서는 WebXR 테스트 씬을 돌려 평균 FPS와 CPU·GPU 사용률을 측정하고 기준선을 벗어나면 실패 처리하도록 자동화하려 한다. 콘텐츠 업로드와 세션 매칭이 같은 DB·UI를 쓰고 있으니, 지금은 한 퀀텀으로 묶고 나중에 필요할 때만 쪼갤 예정이다. |
There was a problem hiding this comment.
XR 프로젝트 적용 계획에 여러 가지 항목이 포함되어 있습니다. 각 계획을 글머리 기호(bullet point)를 사용하여 목록으로 만들면, 개별 항목을 더 명확하게 구분할 수 있어 가독성이 향상될 것입니다.
| 실시간 렌더링 상태와 행동 로그를 다른 저장소·스키마로 나눠 응답 속도와 배치를 분리할 계획이다. ADR 템플릿은 `문제 → 옵션 → 선택 이유 → 부작용 → 재검토 조건` 순으로 짧게 쓰면서도 핵심을 잡을 생각이다. CI에서는 WebXR 테스트 씬을 돌려 평균 FPS와 CPU·GPU 사용률을 측정하고 기준선을 벗어나면 실패 처리하도록 자동화하려 한다. 콘텐츠 업로드와 세션 매칭이 같은 DB·UI를 쓰고 있으니, 지금은 한 퀀텀으로 묶고 나중에 필요할 때만 쪼갤 예정이다. | |
| - 실시간 렌더링 상태와 행동 로그를 다른 저장소·스키마로 나눠 응답 속도와 배치를 분리할 계획이다. | |
| - ADR 템플릿은 `문제 → 옵션 → 선택 이유 → 부작용 → 재검토 조건` 순으로 짧게 쓰면서도 핵심을 잡을 생각이다. | |
| - CI에서는 WebXR 테스트 씬을 돌려 평균 FPS와 CPU·GPU 사용률을 측정하고 기준선을 벗어나면 실패 처리하도록 자동화하려 한다. | |
| - 콘텐츠 업로드와 세션 매칭이 같은 DB·UI를 쓰고 있으니, 지금은 한 퀀텀으로 묶고 나중에 필요할 때만 쪼갤 예정이다. |
|
|
||
| ## 5. 논의 주제 | ||
|
|
||
| 팀 인원이 적을 때 “가벼운 ADR”을 어느 정도 길이로 쓰면 실제로 도움이 되는지 궁금하다. 세 문단 정도면 충분하다고 느꼈는데 다른 분들은 어떻게 기록하고 있는지 듣고 싶다. XR 도메인에서 모듈화 동인을 어떤 지표나 사건을 보고 결정했는지 궁금하다. 콘텐츠 업로드와 실시간 세션을 언제 분리했는지, 현장에서 겪은 기준을 공유해주면 좋겠다. |
There was a problem hiding this comment.
논의하고 싶은 주제가 여러 가지인데 한 문단으로 작성되어 있습니다. 각 질문을 글머리 기호(bullet point)로 나누어 작성하면 다른 참여자들이 질문의 요지를 더 쉽게 파악하고 답변하기 좋을 것 같습니다.
| 팀 인원이 적을 때 “가벼운 ADR”을 어느 정도 길이로 쓰면 실제로 도움이 되는지 궁금하다. 세 문단 정도면 충분하다고 느꼈는데 다른 분들은 어떻게 기록하고 있는지 듣고 싶다. XR 도메인에서 모듈화 동인을 어떤 지표나 사건을 보고 결정했는지 궁금하다. 콘텐츠 업로드와 실시간 세션을 언제 분리했는지, 현장에서 겪은 기준을 공유해주면 좋겠다. | |
| - 팀 인원이 적을 때 “가벼운 ADR”을 어느 정도 길이로 쓰면 실제로 도움이 되는지 궁금하다. 세 문단 정도면 충분하다고 느꼈는데 다른 분들은 어떻게 기록하고 있는지 듣고 싶다. | |
| - XR 도메인에서 모듈화 동인을 어떤 지표나 사건을 보고 결정했는지 궁금하다. | |
| - 콘텐츠 업로드와 실시간 세션을 언제 분리했는지, 현장에서 겪은 기준을 공유해주면 좋겠다. |
benscookie
changed the title
jongfeel
left a comment
jongfeel
left a comment
There was a problem hiding this comment.
pull request를 늦게 올려주셔서 다른 분들이 리뷰를 할 시간이 없었던 것 같습니다.
다음에는 최소 하루 전에는 올려주시면 좋을 것 같아요.
|
|
||
| ## 5. 논의 주제 | ||
|
|
||
| 팀 인원이 적을 때 “가벼운 ADR”을 어느 정도 길이로 쓰면 실제로 도움이 되는지 궁금하다. 세 문단 정도면 충분하다고 느꼈는데 다른 분들은 어떻게 기록하고 있는지 듣고 싶다. XR 도메인에서 모듈화 동인을 어떤 지표나 사건을 보고 결정했는지 궁금하다. 콘텐츠 업로드와 실시간 세션을 언제 분리했는지, 현장에서 겪은 기준을 공유해주면 좋겠다. |
There was a problem hiding this comment.
어제 모임에서 얘기해봤을 때는 ADR을 처음 접해본 분이 많았고, 실제로 작성해본 사람은 저 밖에 없었던 것 같습니다.
내용의 길이가 중요하다기 보다는 문제 인식 - 아키텍처 결정의 이유에 대해 잘 적어 두면 나중에 왜 이런 결정을 했는지 기억할 수 있다는 점에서 좋았다는 얘기를 했었습니다.
XR을 한다면 저는 유니티를 사용하고 있으므로 모듈화는 논리적으로만 가능한 구조였습니다.
콘텐츠 업로드, 실시간 세션은 더 자세한 설명이 필요할 것 같은데 ADR의 아키텍처 결정이라기 보다는 설계 레벨의 인터페이스 부분이라고 보여지네요.
Week1 — Chapters 1~3
1. 내가 이해한 흐름
1장을 읽을 때는 “최고의 설계” 대신 “덜 나쁜 선택”을 골라 기록하라는 메시지가 계속 반복된다고 느꼈다. 운영·분석 데이터 구분, ADR, 피트니스 함수 같은 도구는 그런 선택을 기록하고 지키기 위한 장치처럼 다가왔다. 2장은 아키텍처 퀀텀을 설명하면서 DB, UI, 동기 통신을 공유하면 별도 서비스라도 결국 같은 퀀텀으로 묶인다고 이해했다. 3장은 모듈화를 설득할 때 시장 출시 속도, 가용성, 확장성 같은 비즈니스 동인을 먼저 말해야 한다고 느꼈고, 모놀리식에서 서비스 기반, MSA로 넘어갈수록 격리 이점과 운영 부담이 동시에 커진다는 그림이 그려졌다.
2. 읽으면서 적어둔 포인트
머리에 남은 메시지는 “최선”보다 “덜 나쁜 조합”을 골라 기록해야 한다는 경고였다. 또 아키텍처 퀀텀을 독립 배포 가능한 아티팩트로 이해했고, DB·UI·동기 통신이 엮이면 결국 한 덩어리라고 받아들였다.
3. 주요 인사이트
ADR은 짧아도 꾸준히 남기는 게 낫다고 느꼈다. 두세 문단만 적더라도 나중에 “왜 이 선택을 했는지”를 되짚는 데 충분한 힌트가 된다. 피트니스 함수를 쓰면 감(感)에 의존하는 시간을 줄일 수 있다. 렌더 프레임이나 로딩 시간을 CI에서 자동 측정하면 추측 대신 숫자로 구조를 검증할 수 있다. MSA는 결국 타이밍 싸움이라는 걸 다시 느꼈다. 팀 규모가 작을 때 퀀텀을 늘리면 운영 비용이 훅 뛰니 MVP 단계에서는 의도적으로 한 덩어리로 묶어둔다. 모듈화 메시지는 시장 언어로 변환해야 설득력이 생긴다. “테스트가 쉬워요”보다 “출시 주기가 줄어요” 같은 표현이 훨씬 잘 먹힌다는 걸 실제로 겪었다.
4. XR 프로젝트에 적용
실시간 렌더링 상태와 행동 로그를 다른 저장소·스키마로 나눠 응답 속도와 배치를 분리할 계획이다. ADR 템플릿은
문제 → 옵션 → 선택 이유 → 부작용 → 재검토 조건순으로 짧게 쓰면서도 핵심을 잡을 생각이다. CI에서는 WebXR 테스트 씬을 돌려 평균 FPS와 CPU·GPU 사용률을 측정하고 기준선을 벗어나면 실패 처리하도록 자동화하려 한다. 콘텐츠 업로드와 세션 매칭이 같은 DB·UI를 쓰고 있으니, 지금은 한 퀀텀으로 묶고 나중에 필요할 때만 쪼갤 예정이다.5. 논의 주제
팀 인원이 적을 때 “가벼운 ADR”을 어느 정도 길이로 쓰면 실제로 도움이 되는지 궁금하다. 세 문단 정도면 충분하다고 느꼈는데 다른 분들은 어떻게 기록하고 있는지 듣고 싶다. XR 도메인에서 모듈화 동인을 어떤 지표나 사건을 보고 결정했는지 궁금하다. 콘텐츠 업로드와 실시간 세션을 언제 분리했는지, 현장에서 겪은 기준을 공유해주면 좋겠다.